A known communications system architecture is described in the Telecommunications Information Networking Architecture Consortium (“TINA-C”) document entitled “Overall Concepts and Principles of TINA,” version 1.0, issued Feb. 17, 1995 (hereinafter the “TINA overview”). The overall TINA architecture can include a service architecture having a session model, a network architecture related to transport networks, and a computing architecture having a distributed processing environment (DPE) architecture.
The TINA overview describes a service session concept, where the “session” is defined as representing “a temporal period during which activities are carried out with the purpose of achieving a goal.” Four types of sessions are identified: (i) a service session that represents a single activation of a service, (ii) a user session that represents a single user's interaction with a service session; (iii) a communications session that represents the connections associated with a service session; and (iv) an access session that represents a user's attachment to a system and the user's involvement in services.
A service session, as described by the TINA overview, is a single activation of a service that relates users of the service together so that they can interact. The TINA service session can be controlled at least in part by a TINA service session manager, which offers two types of operational interfaces: (a) a generic session control interface that allows users to join and leave a service session; and (b) service specific operations that are dictated by the capabilities offered by service logic of the service session.
FIG. 1 is an illustration of a known system described in the TINA overview. In particular, FIG. 1 depicts a view of the access and the session concepts. User agents 21 and 22 and terminal agents 31 and 32 represent service independent objects, and the remaining system objects (e.g., TINA service session manager 100, TINA communications session manager 110, user sessions 11 and 12, and end user application 51 and 52) depict service specific objects. When a first user is to engage in a document editing session with another user, the first user can select a terminal on which he will access the network (e.g., a workstation with windowing capabilities). As part of a login procedure, the terminal agent 31 and user agent 21 are found (e.g., using trading services of the DPE) and associated with each other. The user can then be presented with a menu of capabilities and can select a document editing option. A request is passed to the user agent 21 to establish a document editing service session. The user agent 21 creates a document editing TINA service session manager 100, and joins the user to the session, causing a user session 11 to be created. Another menu is presented to the user requesting the identification of the other user to be called. After the user agent receives the identification, the user agent 21 requests that the TINA service session manager 100 join the other user in the session. The TINA service session manager 100 uses the identification to locate (e.g., again via trading) the other user agent 22, and a request to join is sent to the user agent 22. After determining which terminal to alert, the user agent 22 alerts the terminal agent 32 of the incoming session request. The terminal agent 32 then alerts the terminal (e.g., by presenting a window on the user's terminal when the user is already logged on). The other user accepts the request, and the acceptance is sent back to the TINA service session manager 100. After receiving the acceptance, the TINA service session manager 100 creates a user session 12 for the other user. The first user then requests the TINA service session manager 100 to set-up an audio-visual connection to the other user, so that the two users can discuss edits to be made before carrying them out. The TINA service session manager 100 requests the TINA communication session manager 110 to establish a stream 111 between end-user applications 51 and 52 (computational objects) residing on the users' terminals (the interface identities of which were passed over in an earlier request or acceptance). When the stream 111 is established, a response is passed back to the first user. The two users can then engage in an audio-video conversation, where they discuss the changes to be made to the document. The first user can direct the TINA service session manager 100 to open the document, and the document appears on the users' screens. Commands to edit the document are sent to the TINA service session manager 100, and the changes are reflected back on the users' screens. At any time, either party may leave the session, which will result in the other party being notified and the deletion of the service session. During the service session, subject to permission, each user may request another user to join.
FIG. 2 shows an illustration of another known system. In particular, FIG. 2 shows a system based on the Reference Service Architecture of the International Softswitch Consortium. Softswitch 220 and signaling gateway 230 can be coupled to an Advanced Intelligent Network (“AIN”)/Signaling System 7 (“SS7”) signaling network 270 of the public switched telephone network (“PSTN”) 260 to perform call control operations of calls placed over the PSTN 260. In an embodiment, the term PSTN encompasses the interconnected collection of local and long distance phone companies in the United States. A media gateway 240 can receive voice data (e.g., PSTN format data) from a telephone via PSTN 260 and convert the voice data into Internet Protocol (“IP”) data. Data network 250 can be coupled to softswitches 220 and can carry data from one media gateway 240 to second media gateway 240. In an embodiment, data network 250 can be an Asynchronous Transfer Mode (“ATM”) network, an IP network, a MultiProtocol Label Switching (“MPLS”) network, a combination thereof, and so forth. For example, a long-distance call can originate from a first telephone. Softswitch 220 can communicate with second softswitch 220 to set-up the long-distance call across network 250 to a second telephone, where media gateways 240 convert the voice communications between the PSTN format and the IP format.
Application server 200 can be coupled to softswitches 220 to provide a service creation platform. Examples of services that can be created and managed by application server 200 include Internet call waiting, a multimedia conferencing, click-to-dial, and so forth. A media server 210 can also be coupled to application server 200 and to network 250 to provide audio announcements with respect to service applications. For example, a media server 210 can provide announcements to users in setting up a conference bridge for a conference call. Media server 210 can also send audio and/or video streams to one or more users and/or IP endpoints. In an embodiment, the signaling between softswitch 220 and signaling gateway 230 can be ISUP (integrated services digital network user part) signaling, TALI (transport adaptive layer interface) signaling, SIGTRAN (signaling transport) signaling, and so on. Media gateway 240 can be a Media Gateway Control Protocol (“MGCP” or “Megaco”) compliant gateway, and signaling between softswitch 220 and media gateway 240 can be MGCP/Megaco signaling. Communications between data network 250 and media server 210 or media gateways 240 can be RTP (realtime transport protocol) communications. Communications between application server 240 and softswitches 220 can be according to the Session Initiation Protocol (“SIP”).
The AIN/SS7 service creation and execution environment (“SCE”) illustrated in FIG. 2, however, is not adequate for broadband and hybrid messaging services. A softswitch 220 is a voice-oriented call processing engine. Softswitch 220 can behave as a PSTN/IP service creation bridge that allows narrowband service creation (e.g., with IP connectivity via the protocol adaption layer). For converged broadband and/or hybrid messaging services, a softswitch call model is not adequate. Also, converged services with flexible billing (e.g., bill by the minute, bill based on throughput, etc.) and/or user-specified Quality of Service (“QoS”) can not be adequately provided by the softswitch call model. Moreover, a softswitch does not provide session control at the service level, and softswitch vendors typically have different architectures and proprietary Application Programming Interfaces (“APIs”). A large base of hybrid services exist in the IP domain currently, and that base is increasing. Converged service creation, user-specified QoS, and flexible billing can become key service differentiators for communications service providers (e.g., regional communications service providers, data communications service providers, long-distance communications service providers, and so on). In view of the foregoing, it can be appreciated that a substantial need exists for methods and systems for converged service creation environment applications.